There are various parameters that can be configured on the OPC UA Complex Data extension. Take following steps to read or modify them:
Some typical scenarios for which the configuration might be needed are described below.
The data type model provider (DTMP) is an object that provides access to the metadata about data type in the target OPC server(s). The data type model provider also caches the metadata obtained, so that repeated decodings of the same data types do not require retrieving the metadata from the OPC server(s) again and again.
By default, each instance of the EasyUAClient Class has its own data type model provider. If you use multiple instances of the EasyUAClient Class and do not require them be fully isolated in this respect, you should consider switching to a shared data type model provider.
Conceptually, there is no noticeable difference in the results from the default state in which the client objects are set to use per-instance data type model provider. But, with the shared data type model provider, the metadata obtained during the operations on one client object and cached inside the data type model provider are reused during operations on other client objects, making this and the subsequent operations more efficient.
The configuration part that you need to access is the UAComplexDataClientPluginParameters Class.
In OPC Binary data type system, data type dictionaries that reside in the OPC server may use types from other data type dictionaries, and optionally specify location of these other dictionaries, using a string. The OPC UA specification does not define a format for such string.
The OPC UA Complex Data extension already contains data the standard data type dictionary defined in the OPC UA specification, and some others. It also knows how to resolve their namespaces to locations, therefore (by default), the data type dictionaries in the server do not have to specify the location for them.
For other namespaces, the OPC Binary data type system recognizes following syntax for the location string:
If the location string is understood to be a URI, it can be only:
For import directives that do not have their location string specified, the OPC Binary data type system tries to find the location in the WellKnownLocationTemplateDictionary Property. You can therefore access the UAOpcBinaryDtsParameters Class configuration part, and add your entry (entries) to this dictionary, in order to tell the OPC Binary data type system where to find the data type dictionaries. You can specify a node ID in the server if the data type dictionary resides there, or place the data type dictionary into a file, or embed it in a managed resource in your program.
The OPC UA Complex Data is commonly implemented with some bugs on the server side. In addition, at time of writing this article, it is not rigorously (or at all) checked during OPC compliance certification process, and only to very limited extent during OPC Interoperability Workshops. The client must therefore be prepared to handle situations in which the server behavior is erroneous.
We have tested the OPC UA Complex Data extension against several servers with complex data support available, and continue to expand the range of interoperable servers. We have found several issues in these servers (and in the OPC UA specifications) during these tests, and have already provided special coding and configuration inside the OPC UA Complex Data extension to work around these issues.
If you encounter a buggy server and the workaround is not already built into the OPC UA Complex Data extension, you might be able to work around the problem by configuring the extension accordingly. You are also welcome to report the problem to us, so that we can adjust the software and prevent the issue in future versions.
For errors related to the OPC Binary data type system, the configuration part you need to access is the UAOpcBinaryDtsParameters Class.
Here are some common issues with OPC Binary data type system, and their possible workarounds: